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BACKGROUND OF THE INVENTION 

This invention relates to the two-way communication of information, a "posting", 
from a source agent to a target user community via a computer server connected to a 
wide-area network such as the Internet. In particular, the target user community for a 
posting is defined in terms of geographical coordinates, e.g., by a bounded region on a 
map. Targeted users, i.e., those whose geographical location falls within the bounded 
region of a posting, receive notification of the posting either automatically via email, or 
by logging on to the server and browsing for geographically relevant notifications via a 
user interface. 

The system described herein is intended to service mobile users as well as 
stationary users. Mobile users who pass through the targeted area of various postings can 
automatically receive those postings via their wireless connection as they travel, resulting 
in information automatically flowing to them at the posted information's point of 
relevance. 
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Related Art 

[0003] At least three areas of technology are relevant to the present invention: 

geographical product and services databases; one-way communication of information to 
its "point of relevance"; and communication of information via the Internet. However, the 
invention's overall purpose, methods, and implementation differ substantially from all 
known disclosures. Specifically, there is no known Uterature describing a conmiunication 
system that targets unsolicited information to an anonymous user conmiunity identified 
only by a bounded region on a map. 

SUMMARY OF THE INVENTION 

i'^t0004] It is a first feature of the invention to provide a method for associating arbitrary 

Q information with a geographical region of relevance, as defined, e.g., by a closed outhne 
; i on a map. Information so associated with a geographical region of relevance shall be 
W termed a "posting". 

□[0005] It is a second feature of the invention to provide a method for communicating the 

f ^ information content of a posting to individuals who are situated in, or who pass through, 
f y the posting' s geographical region of relevance. 

J:5[0006] It is a third feature of the invention to provide a system that implements these 

'"=^ methods and makes them accessible to a user community via a user interface designed to 
run in the context of a wide area network such as the Internet. 
[0007] This invention empowers people to communicate with one-another through 

geography, rather than by individual identity. In a typical scenario, a user selects a target 
audience by drawing a closed outline around the target community on a map. The user 
then "posts" the desired information to the region thus identified on the map. Potential 
recipients of the information, i.e., those within the designated region, receive notification 
of the posting and can act on its information content in any appropriate way. 
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Example societal uses of this invention are: 

[0008] To ask questions of a local population. For example, if the target region is a 

neighborhood, a user could find a tennis partner, locate a desired item for sale, ask if any 
homes were on or about to come onto the market for sale, or ask a conmiunity-related 
question by "posting to the neighborhood". 

[0009] To ask questions of a larger population. For example, if the target region is a city, 

one family could look for another family wishing to house-swap by posting a request to 
the region. 

[0010] To initiate contact with individuals. If, for instance, the target is a particular home 

within a community, i.e., a very small geographical region, a user could communicate 
directly with the residents of the home without having any prior knowledge about them. 
iOOll] To post community or regional announcements. State, county, and local 

I organizations could post news about topical events to residents in relevant regions. 
il[0012] To post traffic and road construction news. Mobile users could automatically 

receive news about traffic and road conditions relevant to a city block, an interchange, or 
a commuting corridor as they passed through. 
=^[0013] To advertise. The system can be used to implement "virtual billboards". 

Businesses wishing to get their message out could post advertisements to specific 
regions, e.g., several city blocks, or a long narrow region covering a particular section of 
an interstate highway. Mobile users passing through such regions would automatically 
receive the information. 

[0014] To educate and inform. The National Park Service could, for example, post 

information about sites of historical interest. Vacationers, connected to the Internet via 
wireless, would receive such information when visiting the site, or prior to visiting by 
browsing the system's maps. 
[0015] Further features and advantages of the present invention, as well as the structure 

and operation of various embodiments of the invention, are described in detail below with 
reference to the accompanying drawings. In the drawings, like reference numbers 
generally indicate identical, functionally similar and/or structurally similar elements. The 
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drawing in which an element first appears is generally indicated by the leftmost digit(s) in 
the corresponding reference number. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0016] FIG. 1 is a block diagram of a communications system according to an 

embodiment of the present invention. 
[0017] FIG. 2 is a block diagram of a communications system according to another 

embodiment of the present invention, 
[0018] FIG. 3 is an illustration depicting a ping topic user interface screen according to 

an embodiment of the present invention. 
[0019] FIG. 4 is an illustration depicting a visible icon representing a user's home 

antenna on a map, as well as a marker denoting the presence of a photograph that has 

been attached to the map in accordance with an embodiment of the present invention. 

ril 

i 1(0020] FIG. 5 is an illustration depicting a receive channel user interface screen in 

accordance with an embodiment of the present invention. 
□[0021] FIG. 6 is an illustration depicting an account information user interface screen in 

U accordance with an embodiment of the present invention. 

lH[0022] FIGs. 7A-7C depict a new message entry via a user interface screen in accordance 

ry 

iiP with an embodiment of the present invention. 

u[0023] FIG. 7D is a flow chart diagram of a message posting routine according to an 

embodiment of the present invention. 
[0024] FIG. 8 is a flow chart diagram of a message posting routine according to an 

embodiment of the present invention. 
[0025] FIG. 9 is an illustration depicting a ping entry user interface screen in accordance 

with an embodiment of the present invention. 
[0026] FIG. 10 is a flow chart diagram of a ping execution routine according to an 

embodiment of the present invention. 
[0027] FIG. 11 is an illustration depicting a browsing entry user interface screen in 

accordance with an embodiment of the present invention. 



[0028] FIG. 12 is a flow chart diagram of a browsing execution routine according to an 

embodiment of the present invention. 
[0029] FIG. 13 is an illustration depicting a dialog between two users according to an 

embodiment of the present invention. 



i'U 
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DETAILED DESCRIPTION OF THE INVENTION 
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1.0 Overview of the Invention 

[0030] The present invention provides a communications system to post arbitrary 

information to one or more geographical regions. The information is posted by outlining 
or otherwise identifying the region(s) on a map in the system's user interface and 
attaching the information to the outlined region. The outlined region can be of any size, 
e.g., a city block, a neighborhood, a county, and defines the information's "region of 
relevance". Any user of the system can also browse and receive these geographically 
relevant postings simply by identifying a point or region of interest on one of the 
system's maps. The system is useful for facilitating personal communication of questions 
and announcements to a geographically identified group, to providing governmental and 
commercial news and announcements aimed at a particular population, and for presenting 

^'3 virtual billboards for advertising. 

rU 

^ 0 2.0 Exemplary System Characteristics 

m 

2.1 Computer System Embodiment 

lU 

i.y[0031] The present invention provides a communications system to enable anonymous 

□ communication between one or more users. 

'"[0032] Referring to FIG. 1, in an embodiment of the present invention, a communications 

system 100 is comprised of a communications server 111, one or more mobile clients 
109, and one or more stationary clients 105 and 107. In accordance with this 
embodiment, the communications server 111 is implemented as a World Wide Web 
server, although in practice, server 111 could be part of any type of communications 
network. Stationary clients 105 and 107 and mobile clients 109 connect to the 
. communications server 111 over a network (such as a local area network, a wide area 
network, point-to-point links, the Internet, etc., or combinations thereof). Where the 
Internet is used, stationary clients 105 and 107 and mobile clients 109 communicate to 
the communications server 111 via Hypertext Transfer Protocol (HTTP) using standard 
Web browsers. Stationary clients 105 and 107 can be for example, general purpose 
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computers. Mobile clients 109 can be for example handheld personal computers, 
Personal Data Assistants, or the like. 
[0033] The communications server 111 is organized among a series of geographical 

maps that cover the intended service area, e.g., county, metropolitan area, state, country, 
or world, to a sufficient level of visual detail. These maps serve as the basis of much of 
the communications system's 100 user interface (UT). 
[0034] The communications server 111 is further comprised of a HTTP processor 115 

and a map manager 121. The HTTP processor 115 provides for communication between 
the communications server 111, the mobile clients 109, and the stationary clients 107 to 
communicate via HTTP. The map manager 121 manages the maps covering the 
communications system's 100 intended service area. 
, 10035] A user interface 117 is also included with the communication server 111. The 

□ user interface 117 processes user transactions, and dynamically composes HTML 
i=y responses containing maps and other graphical elements (such as icons, photos, and the 
i5 like), drawing in part upon the conmiunications servers's 111 map manager 121. The user 
iii interface 1 17 permits users to interact with the communications system's maps via zoom, 
pan, and drawing primitives, which are implemented partially on the communications 
server 111 side and partially on the cHent 105 or 107 side, e.g., through Java classes 106 
fU and 108 that are automatically made available when the user connects from a stationary 
client. Mobile users would interact with the communication system 100 via an interface 

u 

appropriate to the particular technology of the mobile clients 109 communication devices. 
[0036] The communications server 111 is further comprised of a database 119. The 

database 1 19 stores information about postings, permanent and transient user accounts, 
notifications, email addresses, etc., and is the storage backbone of the communications 
system 100. 

[0037] A postings manager 123 is further included with communications server 111. 

Postings manager 123 stores and retrieves information about postings on demand from 
the user interface 117. 

[0038] The system maintains a postings information database for storing postings. Each 

posting is comprised of an identification tag that describes who has posted it, when it was 
posted, what its posting category is, and other such factual information about its origin. 
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Examples of posting categories are "Personal", "Neighborhood", "Community", 
"Governmental", "Commercial", "Educational", and so forth. Each such category might 
be further refined by subcategories, e.g., Govemmental/Road_Construction. 
[0039] Postings are further defined by an information component, which is the content of 

the posting. As with ordinary email, this component could be just a simple textual 
message, or it could include a reference to one or more Web pages containing graphics, 
audio, links, etc. 

[0040] Each posting is also provided with a "broadcast" descriptor, which identifies the 

posting' s geographical target region(s). In an embodiment, this descriptor would be 
represented by a closed geometrical object such as a polygon or circle in a 2-dimensional 
geographical coordinate space, although it could also include 3-D elevation information 
as well. Users would typically define such a region by using the communications 
Q system's 100 user interface 117 to outline it on one of the conununications system's 
i'h maps. The system would also support compound regions, i.e., regions identified by more 
':5 than one bounded object on the system's maps. 

i:0[0041] The system can also manage an optional password on any posting. For any 

1;"^ posting with a password, the system would require any user wishing to view or receive 

the posting' s information content to present the correct password before allowing the user 
fy access to the posting' s content. This feature would be most useful for communications 

among a group of closely-knit users, such as the residents of a neighborhood or 

community. 

[0042] Administrators of the communications system 100 can restrict the nature of 

postings created by any particular user by defining geographic regions into which the 
user is either authorized or unauthorized to post. Authorized regions can be assigned 
optional passwords and posting category restrictions that further narrow the user's 
posting privileges in those regions. These controls would, for example, permit system 
administrators to grant specific privileges to a regional authority to create postings of 
particular categories, e.g., Governmental/Traffic, GovemmentalAVeather, to particular 
regions, while excluding all other users from posting those categories to the regions. 
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[0043] The communications server 111 is also comprised of a user accounts manager 

125. The user accounts manager 125 stores and retrieves user account information on 
demand from the user interface 117. 

[0044] In an embodiment, user account information is maintained in a database. Each 

user account is comprised of a user identification component, which describes the user's 
identity, e.g., name, email, address, etc., as well as operational preferences and settings, 
such as whether or not automatic email notification of relevant postings is desired. 

[0045] The user account is further comprised of an "antenna" descriptor, which describes 

the user's "base" location, e.g., the location of the user's residence, in geographical 
coordinate space. A user would typically define this antenna descriptor by drawing an 
outline or cross hair on one of the system's maps. In addition to the antenna descriptor for 
the base location, each user account would be capable of maintaining a list of additional 

si: 

3 antenna descriptors, permitting the user to intercept postings relevant to multiple 
^ locations of interest. 

110046] Each user account also includes a notification list, which records postings whose 

0 broadcast descriptor has intersected with one or more of the user's antenna descriptors. 

This list makes the connection between the user and postings that are determined to be 

relevant to that user. 

U[0047] Still further, each user account can also maintain a user-defined list of named 

L; regions. The user can add new regions to this list by drawing an outline on the system's 
^ map, then giving the outlined region a name. Once defined, a named region can then be 
used either in conjunction with reception filters (described below), or as the broadcast 
descriptor for a new posting. 
[0048] A transient accounts manager 127 tracks users who have connected to the 

communications server 111 but who have no registered accounts, and is responsible for 
creating a transient account when such a user connects for the first time, and for garbage 
collecting the transient account after a suitable period of inactivity. 
[0049] Through transient accounts manager 127, the communications server 111 is 

capable of managing a transient antenna descriptor for any user account, i.e., an antenna 
descriptor that would correspond to the continually changing location of a mobile user. In 
typical use, the mobile user's PC or cell phone would have access to Global Positioning 
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System (GPS) technology, and would know its location at any given moment. A mobile 
client 109 would periodically connect to the communications server lllvia its wireless 
channel to the Internet, e.g., every several minutes, and would identify itself as a mobile 
client 109, give its user account ID, if any, and indicate its current GPS coordinates. The 
communications server 111 would record and track this continually changing location via 
the transient antenna descriptor, and would send any non-redundant postings relevant to 
the current location at each check-in time. The communications server 111 would also be 
capable of deducing the user's approximate route in-between check-in points, and would 
automatically find and send any postings deemed to have been appropriate in the missed 
intervals. 

[0050] Transient accounts manager 127 is further used for servicing anonymous users, 

i.e., those with no registered account. Such users could place themselves at arbitrary 
points on the communications system's maps and browse the relevant postings at those 
points. For unregistered mobile users, the communications server 111 would set up and 
maintain a temporary account, including a transient antenna descriptor, that would time 
out and be garbage collected after some predefined period of inactivity. 
'[0051] The communications server 111 is further comprised of an intersection engine 

133. Intersection engine 133 is a pattern-matching engine that constantly runs as a 
background process. This engine is capable of finding intersections between broadcast 
descriptors and antenna descriptors, system-wide. Upon finding an intersection for the 
first time, the engine adds the posting to the notification list of the relevant user account, 
noting which of the user's antenna descriptors "received" the posting. 
[0052] Each user account can accept and store "reception filters", which describe the 

content type and/or broadcast descriptor constraints that any posting must satisfy in order 
for the pattern matching engine 133 to add it to the user account's notification hst. 
Broadcast descriptor filters would, for example, be capable of filtering out postings 
whose target region was too broad, by requiring that the posting's target area be under a 
specified size in square miles in order to qualify for reception. Another type of filter 
would require that the broadcast region have a minimal overiap, e.g., 75%, with some 
user-specified region such as the user's neighborhood. 
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[0053] A notifications manager 129 is capable of presenting notifications to users on 

demand from the UI 1 17 as users browse for relevant notifications. 

[0054] The communications server 111 is also provided with an email manager 131. 

Email manager 131 detects the presence of any newly generated notifications that, based 
upon user preferences, should trigger email, and is responsible for sending email to 
relevant users. 

[0055] The communications server 111 permits any user account to accept and store 

preferences governing the disposition of accumulated notifications. One such preference, 
for example, would direct the server 111 to forward some or all notifications to the user 
as ordinary email. In this case, the end effect would be that the user receives direct email 
from other users whose postings have intersected one or more of the user's antenna 
descriptors. Regardless of whether or not such automatic email has been enabled, the 

0 server would always permit a user to log on and manually browse notifications, or to 
y browse arbitrary regions of the systems maps for postings relevant to those regions, 
in Further description of the features of the communications system will now be described 
m with reference to FIG. 2. 

'•^[0056] In another embodiment a communications system 200 is implemented in a 3-tier 

1 =^ architecture. As shown in FIG. 2, a 3-tier architecture embodiment of the present 
m invention is comprised of: one or more thin clients 205, a middle-tier HTTP server 211 
';0 that responds to thin client 205 requests and implements ttie communications system's 

':ss5 

i'^ 200 business logic, and a distributed, scaleable SQL database tier 213. 
[0057] In the disclosed embodiment, the thin client 205 runs inside a standard Web 

browser such as Microsoft's Internet Explorer, and relies on HTML, JavaScript, and Java 
applet technologies. The middle-tier HTTP server 211 is implemented using such 
technology as Java servlets or Active Server Pages. The distributed SQL database 213 is 
implemented using such technology as Microsoft or Oracle SQL servers. 
[0058] In the disclosed embodiment, there are additional middle-tier servers that are 

capable of performing specific system functions, such as managing user subsets and their 
resources, composing map views, and so forth. Each such server can be requested to 
perform one or more of six logically distinct server roles: USER, ANTENNA, DIALOG, 
ROAM, MAP, and MASTER, as described in sections following. Accordingly, FIG. 2 
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depicts a plurality of USER servers 215, ANTENNA servers 217, ROAM servers 219, 
DIALOG servers 221, and MAP servers 223. USER servers 215 and the MASTER 
server 211, will typically also serve as the middle tier's HTTP servers. The middle-tier 
servers communicate with one another over a high bandwidth network 210. An 
exemplary network 210 is a local area network. The goal of distributing functionality 
across many servers in this way is to maintain good performance and rehabiUty as the 
system grows. Based on average anticipated usage levels, it is estimated that one server 
employing a IGHz PC with 40GB disk storage can adequately support 20,000-40,000 
users. Thus, if the system grew to 20 million users, there would perhaps be 500-1000 
such servers, each performing one or more of the indicated server roles, and all 
interconnected via a high bandwidth LAN backbone at the system's physical site. 
, [0059] As embodied in Fig 2, clients 205 connected via the Internet, contact the 

Q communications system's 200 HTTP servers 211 and 215 through a firewall 213. 

.: SSL 

Jfi[0060] MASTER server 211 supervises user log-ons. The MASTER server's 211 

^ n database contains global system information, such as the identities and addresses of the 
iii other servers, the master list of user names, passwords, and email addresses, and so forth. 
''^ Once a user is logged on, the MASTER server 211 redirects the client 205 to an 

i:^ appropriate USER server 215, which controls the remainder of the session until the user 
i'U logs off or times out because of inactivity. During the course of a user session, various 
other servers (217, 219, 221, and 223) will be called upon to perform database searches 
1 * and other specialized computations in support of user actions and requests. Many of the 
physical servers (211, 215, 217, 219, 221, and 223) also house database servers 213 and 
225 (denoted individually as 225A-225H). Each of these database servers 225 contains 
the subset of the communications system's 200 overall database that is relevant to the 
specialized functions the physical server performs. All database servers 225 are 
accessible on the LAN, so that system functions requiring information from several 
distinct database servers can have seamless access to that information. 
[0061] Computer programs or computer control logic is stored in memory (not shown). 

When executed, these computer programs enable the communications system 200 to 
perform the functions of the present invention as described herein. In particular, the 
computer programs enable a processor 111 to perform the functions of the present 
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invention. Accordingly, such computer programs represent controllers of the 
communications system 200. 
[0062] In an embodiment, the features of the present invention are centralized in a single 

computer system such as communications server 111. In other embodiments, the 
functions of the present invention are distributed among multiple computer systems as 
described in reference to FIG. 2, for example. The invention is not limited to these 
example embodiments. Other implementations of the communications system will be 
apparent to persons skilled in the relevant arts based at least is part on the teachings 
contained herein. 



2.2 Data Representation 

1;J0063] In an embodiment, all system objects including users, antennas, regions, dialogs, 

C3 map photos, ping topics, channels, and so forth, are implemented within the server tier as 
m instances of object classes in a programming language such as Java. SQL database tables 
:^ provide the persistent storage for all instances of each type of object. For example, if an 
□ antenna has been defined, then it will be represented in the server's runtime environment 
as an instance of the Antenna class, and its persistent storage is one row in the SQL 
!!H database's Antennas table. Persistent storage for some objects will involve linked rows in 
iM other tables. For example, when a user channel is defined, its broadcast region may 
I T actually consist of several named regions the user has previously defined. In this case, 
each associated Region object is represented by a row in the Regions table, and is linked 
to the row representing the user-defined channel in the Channels table. Enumeration of 
such class objects and corresponding database tables that are sufficient for implementing 
the functionality of a system as disclosed herein will be provided further below. 
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3 ,0 Exemplary System Operation 
3.1 Map Servers 



[0064] In an embodiment, one or more middle-tier servers are identified as MAP servers 

223. Each MAP server 223, as v^ith each server of other types, is represented in a main 
servers database table as depicted in TABLE 1. 





Field 


DFSrRlPTlON 

1 , 'A* ' '\ < . , " > 




Name 


Server's logical server name 




ComputerName 


Server's physical computer name 


! a 
:;as: 


IPAdress 


Server's numerical IP address 




InService 


Whether or not the server is active 


fU 


ServiceRoles 


List of logical roles the server plays 




TempDirectory 


Server's temp file directory 


m 


AssetsDirectory 


Server's system resources directory 


:.--5 


MapDirectory 


Server's map directory, if appropriate 


iU 


BlobDirectory 


Server's blob storage directory 




HomePagesDirectory 


Server's hosted home pages directory 


m 

■taw 


ReceptionsCacheDirectory 


Server's receptions cache directory 


t . 

y/sat 


MailHost 


Address of mail host for this server 




Table 1 



[0065] MAP servers 223 are dedicated to composing map viev^s on demand from the 

client tier. A view is defined as a rectangular area of interest on communications 
system's 200 national street map. Map data, comprising such elements as road and street 
segments and names, town, city, and feature coordinates and names, and so forth is 
organized by states and counties (or similar units) and stored as files. 

[0066] When requested to compose a view, a map server 223 accesses the relevant map 

data and composes the view at one of a fixed number of "magnification" levels (implied 
by the request). 
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[0067] The map server 223 then returns the results to the client in a suitable format, e.g., 

a GIF file, or a compressed byte stream that can be interpreted by a Java applet running in 
the client tier. For low magnification levels, e.g., views that encompass a very large part 
of the national map, the communications system 200 also makes use of pre-computed 
views, which can be assembled to match requested views, thus avoiding excessively long 
computations. 

[0068] In addition to the fixed geographical map data, a MAP server 223 can also 

dynamically include features that derive from the communications system200 itself, e.g., 
visible Antenna objects, and MapPhoto object markers. 



3.2 Personal Icons 

|; 5:0069] In an embodiment, communications system 200 has a UI that permits a user to 

53 define a personal icon, which can be attached to postings and other user-related messages 
i n throughout the system. Such icons are typically bitmap graphics represented in such 
S standard industry formats as JPEG, GIF, and BMP, which the system stores and 
□ associates with the user's account. Once defined. User interfaces in various parts of the 
U communications system 200 then give the user the option of attaching this personal icon 
!!"H to postings and the other types of system-provided communications described in sections 
below. 

3 .3 Visible Antennas and URL Links 

[0070] The communications system 200 also permits a user optionally to make one or 

more user antennas visible on the systems map UI. When visible, the relevant antenna is 
visually represented either by the user's personal icon, if defined, or by other graphical 
techniques made available to the user. In an embodiment, unlike physical antennas, the 
antennas of the present invention are virtual. When browsing the map, users will see all 
such visible antennas. Visible home antennas are felt to be particularly relevant to 
commercial users, who will want to establish their visual "point of presence" on the map. 

[0071] The communications system 200 also includes a UI that will list all visible 

antennas within the current map view, representing each with a "banner Une" that has 
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been defined by the user and associated with the visible antenna. Each banner line is 
presented as a URL, which, when followed, will zoom a user in to a map view of the 
associated visible antenna. 

Once a user has made an antenna visible on the map, the user also has the option 
of associating a URL with the antenna itself. When such a URL has been defined, the 
communications system 200 permits other users to link to the antenna's URL, e.g., 
display the target HTML page in a secondary pop-up browser window, via an action such 
as Ctrl-clicking the antenna's visible graphical element. This capability makes it 
extremely easy for users to spot a commercial user (a business) on the map and link 
directly to that user's home page simply by clicking on the visible antenna's icon. The 
communications system 200 is also capable of accepting a user-provided home page and 
internally hosting that home page, for users who have no other Web presence. 

3.3.1 Representing Antennas 

I In an embodiment, each antenna is represented by an Antenna object depicted 

below in Table 2. Each such object identifies the owning user via a reference to a User 
object (Table 3), the antenna's geographical coordinates, the antenna's name, and certain 
additional properties such as whether or not the antenna is to be visible on the map. 



ANTENNA TABLE 110 

Field 


[ r .BESCJUFHCM'' 


ID 


Unique ID 


UserlD 


ID of user that owns the antenna 


AntennaType 


"Home", stationary or mobile 


Name 


Antenna's name 


X 


Geographical longitude 


Y 


Geographical latitude 


CreateDate 


Date/time of antenna's creation 


Flags 


Antenna option lags 


DisplayStyle 


Visible/non-visible, and display style 


Display Text 


Display text, if applicable to style 
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LinkURL 


URL to use when antenna icon clicked 


LinkHomePagelD 


ID of system-hosted home page, if any 


Table 2 




User Table 310 


Description 


Field 




ID 


Unique ID 


NamePrefix 


e.g., "Mr", "Mrs" 


FirstName 


User's first name 


MiddleName 


User's middle name, if supplied 


LastName 


User's last name 


NameSuffix 


e.g., "Jr", "in- 


Nickname 


User's preferred nickname 


Address 1 


Address line 1 


Address2 


Address line 2 


City 


City 


State 


State 


ZipCode 


Zip code 


Country 


Country 


SignupDate 


Date/time user joined the system 


AccountType 


Subscription type 


AccountStartDate 


Date/time when subscription type began 


AccountStatus 


e.g., "Current", "Past due" 


ActivationKey 


Initial entry key to use on first log-in 


ActivationKeySent 


Intemal flag (activation key emailed yet) 


Preferences 


User preference settings 


Privileges 


User privileges within the system 


AntennaServer 


ID of user's home antenna server 


IconID 


ID of blob that contains user's icon 


HomePagelD 


ID of blob for intemal home page 


HomeURL 


URL of user's home page, if any 
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LogonCount 


How many times the user has logged on 


LastLogonDate 


Date/time of last logon 


HomeX 


Geographical longitude of home antenna 


HomeY 


Geographical latitude of home antenna 


LastXMin 


User's last map view area 


LastYMin 


etc. 


LastXMax 


etc. 


LastYMax 


etc. 


TABLE 3 



[0074] Each antenna can be selectively enabled or disabled to receive messages on 

1 various channels by the presence of one or more SelectedReceiveChannel objects 
^ depicted in Table 4. 



Selected Receive Channel Table 
270 
FIELD 


DESCRIPTION 


DualKey 


Combo key for fast lookup 


AntennalD 


ID of relevant antenna 


ChannellD 


ID of relevant channel 


EnableEmail 


Whether to forward receptions via email 


Table 4 



[0075] Each SelectedReceiveChannel object logically associates a Channel object 

depicted in Table 5 to the Antenna object. These associations are used during the posting 
broadcast process, as described earlier. A SelectedReceiveChannel object also records 
whether or not the user wants to have receptions on that channel forwarded to the user's 
standard email address. 
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Channel Table 130 


Description 


ID 


Unique ED 


ParentID 


Parent channel ID 


ChannelType 


Channel type, e.g., "public", "user", etc. 


Name 


Channel's name 


Description 


Optional description 


IconName 


Icon file name to use in selection UI 


UserlD 


ID of owner if channel type is "user" 


CreateDate 


Date/time when created (if user) 


Xmin 


Broadcast region bounding area (if user) 


Ymin 


etc. 


Xmax 


etc. 


Ymax 


etc. 


Table 5 



S I 

3 

II 

y 3.4 Ping Topics and Ping 

i[0076] The communications system 200 also permits a user to associate keyword patterns 

with one or more of the user's antennas. A keyword pattern comprises one or more 
keywords logically connected by logical operators such as "and", "oi", and "not". 
Associated with each keyword pattern is an arbitrary message from the user. Such 
pattern/message pairs are referred to as "ping topics", and each ping topic has a name 
(title). One or more ping topics can optionally be associated with any user antenna. An 
example of a ping topic will be explained with reference to FIG. 3 
[0077] In block 301, a user is able to enter the name for a ping topic. In this example 

"Tennis". 
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[0078] In block 303, the user enters the keywords forming the keyword pattern for the 

ping topic. Here, the keywords "tennis" and "partner" are used along with the logical 

operator "and". 

[0079] In block 305, the user is asked to enter the arbitrary message the user wishes to 

send in response to a ping. In this case, the user has entered "Looking for a tennis 
partner? I play at level 4 (on good days!)". 
[0080] In an embodiment, the antenna's owner can also define behavioral preferences for 

any ping topic. Behavioral preferences control the format in which the antenna topic's 
response is returned when hit by a ping. Three examples of such behavioral patterns are 
"Include personal icon in the ping response" 307, "Allow responses to my ping 
response"309, and "Allow user to link to my home antenna"311. 

; [0081] The first option 307 would cause the personal icon of the responding antenna's 

□ owner to be included in the ping response. 

f3[0082] The second option 309 would allow the recipient of the ping response to reply 

back to the antenna's owner, thus initiating a dialog. 

^;fl;0083] The third option 311 would include a link in the ping response, which, when 

□ 

clicked, would take the ping response recipient directly to the antenna's visible icon on 



the map. Behavioral ping topic options such as these are considered to be powerful tools 

\U for commercial users who want to use ping topics to advertise goods and services, and 

i:f1 

.'3 who want to make it easy for users to find their icon and optional home page link on the 
^ map. In response to the user's input, the communications system 200 will create a 

PingTopic object as explained in the next section. 

3 .4. 1 Representing Ping Topics 



[0084] Each Antenna object can optionally have a number of associated PingTopic 

objects. The PingTopic objects are depicted in Table 6. 
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Ping Topic Table 200 


Description 


ID 


Unique ID 


AntennalD 


ID of antenna to which topic belongs 


Name 


Ping topic's name (title) 


CreateDate 


Date/time ping topic was created 


Keywords 


Ping topic keyword expression 


KeywordsID 


ID of text blob if keywords are large 


Response 


Response message to return when hit 


ResponselD 


ID of text blob when response is large 


Flags 


Behavioral flags 


Table 6 



fioOSS] Each PingTopic object comprises (1) a title, (2) a keyword expression that will be 

i[j involved in ping pattern matching, (3) a ping response message to be returned when a 
W pine event matches the keyword expression, and (4) certain behavioral flags. Examples of 

n 

r behavioral flags are whether or not the antenna's owner wants to be able to receive 

llfs responses from users who have successfully pinged the antenna and received its response 

i y 

'U message, whether or not other users should see the antenna owner' s identity, and so forth. 

m 

I * 3.5 Attaching Photos Directly to the Maps 

[0086] In an embodiment, the present invention permits a user to attach one or more 

photographs to the map. The photographs can be for example, JPEG, GIF, TIFF or other 
similarly formatted images. To attach photographs, a UI collects information similar to 
that which is collected for the message component of a posting, namely a title (subject), a 
description (body), and certain behavioral options such as whether other users should be 
able to send messages to the map photo's owner. This UI also permits the user to mark 
the attachment point on the map and optionally indicate a viewing direction (relevant 
when the photo depicts a view of the surroundings from that map point) and a photo 
category, e.g., "View of a Residence", "View of a City Block", etc. Having collected this 
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information, the client tier sends the request to the server tier, which in turn creates a new 

MapPhoto object shown in Table 1. 
[0087] The MapPhoto object will then be available to the communications system's 200 

MAP servers 223 when composing map views. As a result, users will see the map photo 

marker when browsing the map (at a sufficiently high magnification level). 
[0088] Each attached photo is represented on the map by an icon that is visible to users as 

they browse the map. FIG. 4 provides an exemplary illustration of what a user would 

see. 

[0089] When selected in a suitable way, e.g., by Ctrl-clicking the photo's icon 401, the 

communications system 200 displays the photo 403, its message 405, and any supporting 
elements, typically in a pop-up browser window 407. 
. £0090] The owner of a map photo can remove the photo from the map at any time. 

□ Additionally, MapPhoto objects can have an optional lifetime. An ongoing background 

□ 

i n thread looks for expired MapPhoto objects and deletes any it finds. 

\n 

5 
m 



Map Photo Table 180 
Field 


DESCIUPTldN - 


ID 


Unique ID 


UserlD 


User who owns the map photo 


MessagelD 


ID of message associated with photo 


X 


Geographical longitude of photo 


Y 


Geographical latitude of photo 


Direction 


View direction (e.g., "N", "NW",...) 


ContentType 


Photo type, e.g., "residence", "town", ... 


ExpireDate 


Date/time at which the photo expires 


TABLE? 
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3 .6 Channels and Tuning-In 

[0091] The present invention provides multiple channels, which permit a user to describe 

what types of postings to receive on the user's antennas. In an embodiment, there are two 
general types of channels: "system" and "user". 
[0092] A system channel describes a general activity, interest, or sender type. Examples 

of system channels are "Community News", "Local Emergency Agencies", "Fast Food 
(Burgers)", "Personal Search", and so forth. The system has dozens or hundreds of such 
system channels, which characterize various topics of potential interest to all users. In the 
disclosed embodiment, system channels have no geographic basis themselves, but rather 
serve to characterize a posting when it is sent into a user-defmed geographic region. Each 
posting in the new system must be sent on a specific channel. 
J J0093] All users can see all available system channels via a channel guide presented via 

^=3 the system's channel tree UI. FIG. 5 provides an illustration of an exemplary channel 

ry 

in tree in accordance with an embodiment of the present mvention. 

iS[0094] For each of the user' s antennas, the user can selectively tune each system channel 

=3 in or out via the channel guide UI 501. System channels 503 provide a basic level of 
U filtering for the types of postings an antenna will receive. If for example, the home 
\^ antenna, selected in 505, is tuned in to a channel 503 by selection of the channel's 
^ij corresponding box, then any posting sent over the selected channel would be received by 
5 the home antenna (providing the posting' s region included the home antenna). Postings 
sent over channels 503 that have not been selected will not be received. In this way the 
communications system 200 becomes "permission-based", since all users have complete 
freedom to define what it is they want to receive on their antennas. 
[0095] User channels differ from system channels in two important ways. First, there is 

no a-priori collection of user channels; they are instead created and named by individual 
users. Any user with suitable authority, i.e., an appropriate subscription package, can 
create one or more user channels, which that user then "owns". Second, user channels 
have a geographic component. When creating a user channel, a UI prompts the user for 
(1) a system-wide unique name for the channel, (2) a "parent" system channel in the 
channel tree, and (3) the channel's geographic extents, i.e., its "broadcast area". 
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[0096] For each user Channel object, there will be one or more Region objects (described 

below), which collectively describe the channel's broadcast area. 

[0097] The "parent channel" property of a Channel object permits channels to be 

organized hierarchically by categories. This allows users to browse the system's channel 
tree UI 501 to find goods, services, news, etc. of interest when selecting the channels to 
be tuned in by a particular antenna. Hence, when a user creates a new channel, the user is 
requested to place the new channel at the appropriate point in the channel hierarchy. For 
example, if a new channel is a commercial channel owned by a pizza retail shop, then the 
owner would typically place the new channel under the abstract system channel "Fast 
Food, Pizza Coupons" where it will be readily found by users who may wish to tune in to 
it. 

. 10098] Once defined, a user channel will pop into view in the channel guide (under the 

■ 3 appropriate parent channel) for all antennas that lie within the channel's broadcast area. 
m For example, if a commercial user in the Washington, DC area defines "The Merrifield 

Home Depot Channel", then only users who have an antenna situated in the channel's 
iio broadcast area around Merrifield, VA will see the channel as a choice in their channel 

euides Users in San Francisco, and everywhere else outside the broadcast area, will not 

if ^ 

see the channel in their channel guides. When visible in a user antenna's channel guide, 

fU 

f U the user has the option of tuning in or tuning out the user channel. 
;:^[0099] User channels thus provide a refined way for conunercial users to reach their most 

1* geographically relevant prospective customers. Businesses can employ user channels to 
broadcast electronic coupons and news about special deals, for example. News agencies 
can broadcast neighborhood-specific news to precisely targeted user groups, and so forth. 
User channels are therefore an abstract analog of physical radio and TV stations, although 
user channels afford a more precise control over the broadcast area than their real-world 
counterparts. 

3 .6. 1 Representing and Managing Channels 

[00100] In an embodiment, each broadcast channel is represented by a Channel object 
illustrated in Table 5. Each broadcast channel is comprised of a name, a description, a 
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type, and a reference to a "parent channel". Additionally, if a channel is a user channel, 
i.e., one that has been created and named by a user, the Channel object will also contain a 
reference to the user, the creation date, and information about the channel's broadcast 
region extents. 

[00101] In an embodiment, there are at least four system channel types, "abstract", 
"public", "commercial", and "restricted", as well as "user" channels. "Abstract" system 
channels cannot actually be sent on, but rather serve to define general categories in the 
channel tree hierarchy, e.g., "Community Services", "Emergency News", "Fast Food 
Coupons". Other channels representing sub-categories will exist beneath each abstract 
channel. "Public" system channels are available to all users. "Commercial" system 
channels are available only to users with appropriate account types. "Restricted" system 
channels are assigned at the discretion of system administrators, and are made available 

ra only to users who have positively identified themselves as relevant uses of the channel, 
e.g., the "McLean VA Police Emergency" channel. Restricted channels will generally 
have an associated broadcast region, defined by one or more Region objects agreed to by 

iii system administrators. Restricted channels are somewhat analogous to certificates of 

'l'^ trust, in that they represent trusted sources. 

i * [0100] As previously explained, user channels are those that have been created and 

fit 

m named by users with an appropriate subscription package. User channels have intrinsic 

S J broadcast regions, which are defined by one or more user-supplied Region objects, which 

M are associated with the user channel via ChannelRegion objects depicted in Table 8. 



CHANINEL REGION TABLE 140 
FIELD 


Description 


ChannellD 


ID of relevant channel 


RegionID 


ID of relevant region ("broadcast area") 


Tables 



[0101] Public and commercial channels do not have intrinsic broadcast regions, since 
each posting sent on such channels will define its own broadcast region via one or more 
Region objects supplied by the sender at posting time. 
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[0102] The system further provides a UI that permits a user to identify a set of "favorite 
send" channels from the channel tree. The list of favorite send channels, each represented 
by a FavoriteSendChannel object (Table 10), is displayed as the first step of the posting 
process, although the user also has the option of selecting a posting' s send channel 
directly from the channel tree. 



FAVORITE Send 
Channel Table 160 
Field 


DESCIUPTION r 


UserlD 


JD of relevant user 


ChannellD 


ID of relevant "favorite" channel 


Table 10 



3.7 Representing Regions 

[0103] In the disclosed embodiment, each region in the system defines a (possibly 
compound) bounded area on the map, and is represented by a Region object (Table 11), 
which comprises one or more closed polygons in the map's coordinate system. 



REGION Table 260 
Field 


Description 


ID 


Unique ID 


UserlD 


ID of user who owns this region 


Name 


Region's name 


CreateDate 


Date/time of region's creation 


Xmin 


Region's bounding rectangle 


Ymin 


etc. 


Xmax 


etc. 


Ymax 


etc. 


Descriptor 


ASCn string describing polygon 


DescriptorlD 


ID of text blob if descriptor is large 


Table 11 
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[0104] A Region object can also have an optional name, which is assigned by the user at 
the time the region is created via the system's region drawing UI. Regions provide the 
basis for defining a posting' s broadcast area, for user-defined channels' broadcast areas, 
and for pinging a desired area of the map. A Region object is capable of determining 
whether a given point is contained in one of its component polygons, using a standard "is 
point in polygon" algorithm. 

[0105] In an embodiment, the system is capable of maintaining a Ust of named regions 
that have been created by a user, and of presenting this list when the user composes a 
posting. The posting region can thus be defined to include one or more of these named 
regions. Alternatively, by drawing one or more closed polygons on the map, a user can 
create an unnamed Region object to identify a posting' s broadcast area. A Region object 
can also be created impUcitly to represent the current (rectangular) map view, in case the 
user chooses to post into or ping the region implied by this current view, i.e., without 
bothering to outline a specific area. 

3.8 Managing Dialogs 

[0106] The system can support dialogs between individuals who have come in contact 
with each other via the various means provided by the system. Postings, as described 
above are one way a user comes in contact with another user. Ping topics and pinging 
provide a second way for one user to come in contact with another. Photos attached to the 
map provide yet another way for users to contact one another. Regardless of which of 
these three methods resulted in initial contact, the system gives the "originating" user, 
i.e., the sender of the posting, the owner of the ping topic, or the owner of the map photo, 
the option of enabling "receiving" users to respond. In this way a dialog between the 
users is made possible. 

[0107] Dialog objects (Table 12) record ongoing message streams between two users. 
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dialog table 150 
Field 


descmption 


ID 


Unique ID 


FromUserlD 


ID of user who initiated dialog 


ToUserlD 


ID of other user 


RefType 


How the dialog began, e.g., "posting" 


Subject 


Message title of initiating event 


CreateDate 


Date/time at which the dialog began 


Flags 


Behavioral flags 


Table 12 



[0108] Each Dialog object includes a reference to the user who sent the initial message, a 
reference to the user who is the recipient of this first message, and a reference to the 
object in the system that enabled the dialog's inception (Posting, PingTopic, or 
MapPhoto). 

[0109] As the users' discourse progresses, message objects (Table 13) are accumulated. 



Message Table 190 
Field 


Description 


ID 


Unique ID 


FromUserlD 


ID of message's sender 


ToUserlD 


ID of recipient user 


DialogID 


ID of dialog of which a part, if any 


CreateDate 


Date/time message was created 


Subject 


Message's subject (title) 


Body 


Message's body 


BodylD 


ID of text blob if body is large 


PhotoID 


ID of photo blob, if any 


AudioID 


ID of audio blob, if any 


DocID 


ID of document blob, if any 


LinkURL 


URL of attacked link, if any 


Flags 


Message's behavioral options 
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Status 


Flags (e.g., "new", "viewed") 


TABLE 13 



[0110] Each Message object refers to the parent Dialog object (Table 12). Either of the 
dialog's users is free to delete any or all of a dialog's messages, as well as the entire 
dialog, at any time. 

[0111] In a large system, many servers, identified in the Servers database table as 
DIALOG servers 221, might play the role of dialog server. Each DIALOG server 221 
will manage a subset of the system's overall Dialog and Message objects, allowing the 
system to scale arbitrarily. 

3.9 Managing Users and the Log-on Process 

[0112] One or more servers, identified as USER servers 215 in the main Servers database 
table (Table 1), manage a subset of the overall system user population. These servers are 
typically also the HTTP servers to which the client tier connects when making requests. 

[0113] Each user is represented by one of the User objects previously described (Table 
13). 

[0114] Each user is further represented by one entry in the UserMasterlndex database 
table shown below in Table 16. The UserMasterlndex database table is stored on the 
single server that has been designated as the system's MASTER server 211. 



USER MASTER ENTRY TABLE 300 
FffiLD 


Description „ - 


LogonName 


User's unique log-on name 


Password 


User's log-on password 


Email 


User's email address 


UserlD 


User's ID 


Administrator 


Administrative flags 


Table 16 
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[0115] Each User object uniquely identifies and describes one user of the system. Each 
entry in the UserMasterlndex table contains the critical information enabling the user to 
log on (log-on name and password), as well as the user's system-wide unique email 
address. 

[0116] When a user attempts to log on to the communications system 200, the client tier 
205 passes the log-on name and password that have been entered to the system's 
MASTER server 211, which is also an HTTP server. The MASTER server 211 validates 
the information, and upon success, redirects the client tier to the USER server 215 that 
hosts the user, who has now been identified. 

[0117] UserEvent objects, represented in Table 17, are created by various user actions 
that consume system resources, e.g., postings, pings, roaming check-ins, etc. 



USER Event TABLE 290 
Field 


Descriptiqn : 


UserlD 


ID of relevant user 


EventType 


Type of user event, e.g., "logon", "ping" 


EventDate 


Date/time of the event 


EventData 


Ancillary information about the event 


Table 17 



[0118] Using the information contained in the UserEvent objects, the conmiunications 
system 200 can perform checks that ensure that usage limits do not exceed the limits 
associated with the user's subscription package. Likewise, AccountAction objects (Table 
18) track user account activities, such as payments received when a user obtains a more 
advanced subscription package. 
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ACCOUNT ACTION TABLE 100 


Description 


ID 


Unique ID 


UserlD 


ID of relevant user 


ActionDate 


Date/time of the action 


ActionType 


e.g., "subscription upgrade" 


ActionStatus 


Flags indicating action's status 


ActionChargeCents 


Charge to user, if any 


ActionComments 


Action comments, if any 


Table 18 



[0119] Problem objects (Table 19) record user problems, requests, etc., and serve as the 
system's foundation for on-line customer service. 



PROKLEM TABLE 230 

Field 


DESCMPTIpN 


ID 


Unique ID 


UserlD 


ID of relevant user 


ProblemDate 


Date/time when problem was logged 


ProblemCode 


Internal code indicating problem type 


ProblemTopic 


Subject supplied by user, if any 


ProblemDesc 


Description supplied by user, if any 


ResolvedBy 


ID of administrative user who solved 


ResolutionDate 


Date/time problem was solved 


ResolutionCode 


Internal code indicating how solved 


ResolutionDesc 


Administrative conmients, if any 


Table 19 



[0120] Referral objects (Table 20) are created when a user opts to refer the system to a 
friend who is not yet a member of the system. This process also generates an automatic 
email to the prospective user. 
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Referral Table 250 
Field 




ID 


Unique ID 


ReferringUserlD 


ID of user making the referral 


ReferralDate 


Date/time of the referral 


X 


Proposed antenna longitude 


Y 


Proposed antenna latitude 


NewUserEmail 


Email address of referred individual 


EntryKey 


Speed key for referred user to see map 


Subject 


Referral message's subject 


Message 


Referral message's body 


EmailSent 


Internal flag (referral email yet sent) 


NewUserlD 


ID of referred user if signs up 


Table 20 



[0121] HomePage objects (Table 21) and associated Blob objects (Table 22) are created 
when a user submits a home page to be internally hosted by the system. Blob objects are 
also created when photos, audio clips, and other ancillary files first enter the system. 



Home Page Table 170 
Field 


DEiSCRIPTrON . > 


ID 


Unique ID 


Path 


Storage path of home page materials 


InitialPageName 


HTML file name of initial page 


CreateDate 


Date/time home pages were checked in 


Table 21 
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BLOB TABLE 120 


Description 


ID 


Unique ID 


Name 


Name, if relevant (e.g., photo title) 


FileRole 


Type of object the blob represents 


FileType 


Physical file format, e.g., JPEG, WAV 


Path 


Physical storage path of the file 


CreateDate 


Date/time blob was created 


Table 22 



3.9. 1 User Account Types 



[0122] In an embodiment, communications system 200 classifies users by account types, 
which are defined by subscription packages. Each account type grants or denies access to 
various system features and resources, defines usage level limits. For example, ttie ability 
to define user channels is granted only to users of a particular account type or higher. 
Visible home antennas are available only with certain account types. Posting region size 
and distance, and ping regions and weekly ping hit counts are examples of system usage 
Umits that are imposed by the various account types. A UIs permits a user to upgrade to a 
more advanced subscription package, and hence account type, on request. 

3.9.2 User Account Information 

[0123] In an embodiment, users of the communications system 200 can request 

information about their current registration. Referring to FIG. 6, in response to such a 

request, an account information UI screen 601 is presented. 
[0124] Field 603 indicates the current e-mail address that the user has registered with the 

conmiunications system 200. 
[0125] Field 605 indicates the current mailing and or residential address of the user. 
[0126] Field 607 indicates the current location of a base antenna assigned to the user. 

The base antenna's location is represented in latitude and longitude directional 

coordinates. 
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[0127] If the user has additional antennas, then the name and coordinates of these 
antennas would be displayed in field 609. 

[0128] Field 61 1 is used to list the names of regions that the user has defined. 

[0129] Field 613 is used to summarize a user's notification filters. Here, for example, a 
user has three notification filters associated with the antennas "Home", "My Office", and 
"Bill's Office". Each of these antennas are tuned to receive postings on the categories 
indicated in the "Post Category' column. In the event the boundaries of one region over 
lap with the boundaries of another, then the regions are identified in column entitled 
"Overlaps with" and the degree of overlap is indicated in the column labeled "by %". 
Finally, the users desire to receive e-mail notification of any postings satisfying the 
notification filters is indicated by selection of the corresponding boxes in the column 
labeled "Send as Email". 

4.0 Representing Postings 

[0130] In an embodiment, each posting is represented within communications system 
200 as a Posting Object, illustrated below in Table 23. Each posting object is comprised 



of a linkable URL displaying the posting message's subject and message body. 



posting table 220 
Field 


EfESCRIPTION 


ID 


Unique ID 


UserlD 


ID of user who created the posting 


ChannellD 


Channel on which posting was sent 


MessagelD 


ID if relevant message object 


RegionID 


ID of posting region, if relevant 


Status 


e.g„ "sent", "pending" 


CreateDate 


Date/time of the posting 


ExpireDate 


Expiration date of the posting 


ProxylD 


ID of posting proxy server 


HitCount 


Count of antennas initially hit 


MobileHitCount 


Count of antennas hit by roam check-ins 


TABLE 23 
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4. 1 Representing Posting Proxies 

[0131] In an embodiment where processing is distributed among multiple servers, for 
example USER servers 215 and ROAM servers 219, a PostingProxy object is created. 
An exemplary PostingProxy object is illustrated below with respect to Table 24. The 
PostingProxy object, stored on ROAM servers 219, is a surrogate for the Posting object 
(Table 23) which would be stored on the USER server 215. 



POSTING PROXY TABLE 230 
Field 


BESCMPTlpN , ; i 


ID 


Unique ID 


PostingID 


ID of relevant posting 


CreateDate 


Date/time posting was sent 


ChannellD 


ID of channel on which posting was sent 


RegiotilD 


ID of posting region 


Xmin 


Posting region's bounding rectangle 


Ymin 


etc. 


Xmax 


etc. 


Ymax 


etc. 


Table 24 



4.3 Representing Receptions 



[0132] In an embodiment. Reception objects, depicted in Table 25, are created to denote 
reception of an event for an antenna (e.g., receipt of a message). 



RECEPTION Table 240 
Field 


Description: 


ID 


Unique ID 


AntennalD 


ID of antenna on which received 


ChannellD 


ID of channel on which received 


PostingID 


ID of posting received 


ReceptionDate 


Date/time of the reception 
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Status 


Internal status flag ("new", "viewed") 


EmailStatus 


Email flags, if forwarding requested 


Table 25 



5 .0 Exemplary System Usage 



5 . 1 The Posting Process 

[0133] Postings provide one way for a user to initiate a contact with other users of 
connmunications system 200. An exemplary message posting shall now be described 
with reference to HGs. 7A, 7B, 7C, and 7D. Referring to FIG. 7A and 7B, in an 
embodiment, communication system 200 prompts a user for the following information 
when the user elects to send a new posting: (1) the broadcast channel, (2) the broadcast 
region, (3) the message contents, and (4) several behavioral options. 

[0134] Accordingly, as shown in step 7D02 of FIG. 7D, the user identifies a broadcast 
channel in the user input box 7A13. In an embodiment, the broadcast channel identified 
has a channel description related to the subject of the message. 

[0135] Next, in step 7D04, the user identifies a broadcast region descriptor associated 
with the identified broadcast channel. This entry is made into user input box 7B15. In an 
embodiment, the broadcast region descriptor is comprised of one or more geographical 
regions into which the message is to be communicated. In an alternative embodiment, the 
identified broadcast channel is not a user channel with a predefined broadcast region 
descriptor. In this case, the broadcast region descriptor is defined in real time as depicted 
in user input box 7B17. 

[0136] Next, in step 7D06, the user enters the message to be conraiunicated using for 
example, user input box 7C03. In an embodiment, the message can be composed of one 
or more message components such as text data, image data, audio data, or linking data for 
accessing a page on the Internet. In accordance with this embodiment, the attachment of 
additional message components can be identified in user input boxes 7C05. 

[0137] Next, in step 7D08, the user selects one or more behavioral options via input 
boxes 7C07. Exemplary behavioral options include whether to reveal a name associated 
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with the user (i.e., originator of the message to the target user community), whether to 
reveal an electronic mail address associated with the user, and whether to allow the target 
community to communicate a reply to the user. The behavioral options might also 
include a link to a universal resource locator for directing the user to a specific web site 
on the world wide web. 
[0138] Finally, in step 7D10, the user causes the message to be transmitted by, for 
example, selecting an input prompt such as the user input icon 7C11. In response, the 
message and said behavioral options are transmitted for further processing and 
communication to the target user community. 
[0139] The broadcast region comprises one or more Region objects (Table 11), each of 
which comprises a set of one or more closed polygons on the map. The message contents 
comprise a subject (shown in 7C01), a body (shown in 7C03), and one or more optional 
attachments identified in 7C05 (e.g., a photo, an audio clip, a document, or a URL link). 
Behavioral options 7C07 include such preferences as whether or not others should see the 
sender's identity, whether or not the sender wants to enable replies to the posting, and so 
forth. All postings also have a lifetime indicator 7C09, which can be controlled within 
system-defined limits, e.g., from one day to one month. An ongoing background thread 
automatically deletes all postings whose lifetime has expired. 
[0140] Referring to FIG. 8, in an embodiment, upon collecting the information relevant 
to a posting ^IGs. 7A-7D), in step 801, the communications system's 200 client tier 205 
sends the posting request to the server tier 21 1, which verifies its integrity. 
[0141] In step 802, a new Posting object (Fig. 10, 220) is created. The new Posting 
object binds all relevant information together as one new row in the Postings database 
table. Supporting objects are also created in other database tables as part of this process. 
For example, a new Message object (Table 13) is created to represent the message 
contents, and this object might in turn have supporting Blob objects (Table 22) that 
represent the message's optional attachments. At this point, the posting exists in both 
runtime and persistent storage form, and must be "broadcast" so that antennas within its 
broadcast region that are tuned to the posting' s channel will receive the posting. 
[0142] Next, in step 803, potentially relevant antennas are located by an approximate 
search on the system's Antennas database table (Table 2) and a hit list is created. The 
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goal of this step is to identify all the antennas within the targeted user community that 
should be notified of the message posting. Since in a production environment, the 
Antennas database table might be distributed among many "antenna servers", the search 
might actually be initiated in parallel on many such servers, which are identified as such 
via Server objects stored in the system's main Servers table (Table 1). 
[0143] For each Region object (Table 11) in the posting's broadcast region, that Region 
object's geographical extents, (xmin, ymin, xmax, ymax), are retrieved. The search on the 
Antennas table(s) first locates all antennas that fall within the Region's geographical 
extents, and that have been enabled to receive postings on the posting's channel. These 
antennas are referred to as candidate antennas. All of the antennas within the Region's 
geographical extent will not necessarily be within the broadcast region. For example, a 
Region object's geographical extents might cause it to partially overlap the broadcast 
region as opposed to being fully within it. In this case, it is necessary to separate from all 
the antennas that fall within the Regions geographical extents, those antennas that are 
actually within the broadcast region. Accordingly, for each candidate antenna, using a 
standard "is point in polygon" algorithm, a specific check is made to determine whether 
the antenna actually lies within the broadcast region. The subset of all antennas that pass 
these tests comprise the posting's "hit set". 
[0144] Finally, in step 804, for each antenna in the hit set, a Reception object (Table 25) 
is created to denote the reception event for that antenna. Specifically, the new Reception 
object logically binds the Posting object (Table 23), the Channel object (Table 5), and the 
Antenna object (Table 2) together, and notes the date and time of the reception. In a 
preferred embodiment, the posting's Message object is not actually rephcated, as it would 
be in an email system, but rather simply referred to by the Reception object. There are 
four benefits to this approach: First, it significantly reduces compute time and storage 
requirements, since only one copy of the posting exists for the (potentially thousands of) 
Reception objects that refer to it. Second, the posting's user can delete ("recall") the 
posting instantly from all prospective recipients, a feature thought to be important in an 
open, public system such as this. Third, the act of deleting a received posting is 
simplified, since only the Reception object needs to be deleted. Fourth, since all Posting 
objects will eventually be deleted either by their sender or by the system thread that looks 
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for expired postings, eventually all traces of each posting will eventually be removed 
from the system, avoiding a buildup of copies of the posting. 
[0145] The act of creating a Reception object can also result in a standard email message 
being sent to the antenna's owner. This case will occur when the user has indicated that 
messages received on the Reception object's channel are of enough potential interest that 
they should be forwarded to the user's normal email account, in addition to being 
recorded inside of the system. For receptions on channels marked for email forwarding, 
the system composes a summary of the new reception, then sends it to the user's normal 
email account via an SMTP mail host. 

5.2 The Ping Process 

[0146] The system permits users to "ping the map" by outlining a region on the map UI 
and entering ping keywords, also optionally interconnected with logical operators, then 
requesting a "ping". Upon receiving such a request, the system is capable of finding any 
antennas within the outlined region that have at least one antenna topic determined to 
match the supplied ping keywords. Upon finding all such matches from various antennas 
in the outlined region, the system is capable of returning the Ust of ping hits. Each ping 
hit shows the ping topic's message, possibly along with other optional information about 
the ping topic's owner. 

[0147] An exemplary method to ''ping the map"will now be described with reference to 
FIG. 9 and FIG. 10. 

[0148] Referring to FIG. 9, a user first identifies a map region 903 using the system's 
ping UI 901. In an embodiment, the map region 903 is identified by drawing a closed 
polygon that is internally represented by a ping Region object (Table 11). 

[0149] Next, a keyword expression 905 is entered. 

[0150] Finally, the ping request is submitted by clicking the ping request 907. 

[0151] Referring to FIG. 10, in a first step 1001, upon receiving the ping request from the 
chent tier 205, the communications system's server tier 215 finds candidate antennas in 
the selected map region 903 using an algorithm similar to that described for locating 
initial candidate antennas to receive a posting. 
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[0152] Next, in step 1003, for each candidate, a specific check is made to deteimine 
whether the candidate antenna actually is contained by the ping region object. 

[0153] In step 1004, for each candidate antenna contained by the ping region object, an 
appropriate pattern-matching algorithm is applied to determine whether or not the ping 
keyword expression matches the keyword expression of any of the antenna's PingTopic 
objects. Each PingTopic object (Table 6) thus found to match is added to the ping's *'hit 
list". 

[0154] Finally, in step 1005, the user server 215 sends a summary of the results back to 
the client tier 205, representing each hit by the ping topic's title, message, and any links 
enabled by the ping topic's behavioral options. For example, if the ping topic enables 
responses, then the hit will have an associated "Reply" option; if the ping topic enables 
users to zoom to the ping topic's (visible) antenna, then the hit will have an associated 
"Show home" link, and so forth. 

[0155] In a large system embodiment, a ping request will be routed to many ANTENNA 
servers 217 in the middle tier. Each such server 217 hosts a subset of the overall 
population of Antenna objects, and is capable of performing the algorithms described in 
order to obtain a hit list. The union of all such lists from all ANTENNA servers 217 is 
then returned to the client tier 205. System parameters can be set to limit the number of 
ping responses from each server, to keep hit set sizes within reasonable limits. 

5 .3 The Roam Check-In Process 

[0156] Referring to Fig. 1 1 , the communications system 200 also provides a UI 1 101 that 
permits a user interactively to move a mobile antenna 1103 around the map 1105, 
simulating the movement of the mobile antenna 1103 as though it were in an actual 
vehicle. Each repositioning of the mobile antenna 1103 causes a check-in event, in which 
the system looks for postings relevant to the mobile antenna's new location and not yet 
received by the antenna. This feature permits a user to "roam the map", from UI 1101 
instead of an actual vehicle, thereby discovering postings at places of interest around the 
map. As with "stationary" antennas, a mobile antenna 1103 will receive only those 
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system channels to which it has been tuned, and only those user channels whose parent 
system channel has been tuned in. 
[0157] A roaming check-in occurs from the client tier when a mobile antenna 1103 
identifies itself and its location to the server tier 215. Such a check-in can occur either 
from a truly mobile antenna, where the client tier 205 is running in a mobile, GPS- 
enabled PC, or from the previously described manual roaming UI 1101, from which a 
stationary user can simulate the movements of a mobile antenna 1103. The goal of the 
roaming check-in is to find any postings that hit the mobile antenna 1103 in its current 
location, and which have not already been received by the mobile antenna 1 103. 
[0158] FIG. 12 provides an exemplary method for executing a roaming check in 

accordance with an embodiment of the present invention. 
[0159] In step 1201, upon receiving a roaming check-in, the server tier 215 first finds a 
set of initial candidate postings whose broadcast region's extents 
(xmin,ymin,xmax,ymax) contain the mobile antenna 1103, and whose channel (or its 
parent channel in the case of user channels) has been tuned in for the antenna. 
[0160] In step 1203, for each initial candidate, it is determined whether or not the 
antenna's location is actually contained by one of the broadcast Region objects. Each 
posting found to contain the antenna's current point becomes a final candidate. 
[0161] Then, in step 1205, for each final candidate posting for which a Reception object 
does not already exist for this mobile antenna 1103, the server 215 generates a new 
Reception object and adds the posting to a hit list. 
[0162] Finally, in step 1207, the server tier 215 returns a summary of the hit list to the 
client tier 205, with each Posting object represented by a linkable URL displaying the 
posting message's subject and message body. The user can then retrieve and view any 
posting on the hit list by cUcking on its link. 
[0163] As with ping processing, in a large system embodiment, a roaming check-in 
request will typically be routed to many servers identified as ROAM servers 219 in the 
Servers database table, each of which hosts a subset of the overall population of 
PostingProxy objects (Table 24). 
[0164] A PostingProxy object is a surrogate for an actual posting, which itself will 
typically be stored on the USER server 215 that hosts the user who sent it. PostingProxy 
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objects stored on ROAM servers 219 allow the computationally intensive work of 
roaming check-ins to be distributed across any number of servers, each of which 
performs the algorithms described and returns a hit list. In accordance with this 
embodiment, the union of all such lists would be returned to the client tier 205 as the 
response to the roaming check-in (step 1207). As with ping processing, system 
parameters can limit the number of postings from each roam check-in server to keep hit 
set sizes within reasonable limits. 

5 .4 The Dialog Process 

[0165] A response to one of the described initial contact events (i.e., ping, post, and 
photos/icons) starts a dialog between the receiving user and the originating user. From 
that point on, both parties will be able to see the dialog in the system's dialog UI, an 
exemplary illustration of which is provided in HG. 13. Also, once the dialog exists, both 
parties can add new messages to it, providing a two-way communication mechanism 
between the parties, even though either or both may choose to remain anonymous. 
Messages sent as part of the dialog can include attachments such as photos, audio clips, 
and external documents. Dialogs are terminated, i.e., removed from the system, either 
explicitly by one or both parties, or by other system rules based on such parameters as 
age or disuse. 

6.0 Conclusion 

[0166] While various embodiments of the present invention have been described above, 
it should be understood that they have been presented by way of example only and not 
limitation. It will be understood by those skilled in the art that various changes in form 
and details may be made therein without departing from the spirit and scope of the 
invention as defined in the appended claims. Thus, the breadth and scope of the present 
invention should not be limited by any of the above-described exemplary embodiments, 
but should be defined only in accordance with the following claims and their equivalents. 



